home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 1 / QRZ Ham Radio Callsign Database - December 1993.iso / ucsd / packet / tcpip / sys5 / iscwmpst.z / iscwmpst / tcp / src / notes < prev    next >
Encoding:
Text File  |  1991-07-24  |  22.9 KB  |  556 lines
  1.  ===============================================================================
  2.  
  3. > Hm ich wuerde sie auch nicht verstehen. War wohl ein bissl im Tran vorhin.
  4. > Ich meinte, dass ich meine Sessions auf die Funktionstasten gelegt hatte,
  5. > d.h. mit f1 die erste, f2 die zweite etc., einfach aus der Faulheit
  6. > heraus, <esc> und dann 'sess x' einzugeben. Auf F10 habe ich mir den
  7. > Status-Befehl gelegt. Meine Frage war, ob's auch bei den HP-Terminals
  8. > Funktionstasten gibt, und ob die Ansi-Sequenzen da irgendwie genormt sind.
  9. > Bei mir ist f1 z.B. ^[OP, f2 ^[OQ usw.  Wenn die Terminals da kompatibel
  10. > waeren, koennte man damit auch das esc-Problem erschlagen, da dann der
  11. > Druck einer F-Taste zum Wechseln der Session bzw. zum Wechseln in den
  12. > Commandmode fuehren wuerde.
  13. > Hoffentlich war das jetzt verstaendlich, werde nun erstmal ins Bett gehen,
  14. > sonst kommt eh nichts mehr raus.
  15. > 73s,
  16. > noch einen schoenen Abend
  17. > Olaf
  18.  
  19. Jetzt habe ich Dich  verstanden.  Die Codes fuer HP  Terminals  und ANSI
  20. Terminals sind zwar verschieden, aber das eigentliche  Problem ist, dass
  21. der  momentane  ttydriver  so lange  Sequenzen  nicht  dekodieren  kann.
  22. Bisher versteht er nur
  23.  
  24.   ESC   [   <char>
  25.         ^
  26.         |
  27.      optional
  28.  
  29. Langfristig  koennte man das schon einbauen, aber momentan  drueckt mich
  30. das CRC Problem mehr.
  31.  
  32. ===============================================================================
  33.  
  34. - CHECK:        overflow in mail buffers
  35.  
  36. - IMPLEMENT:    ax25 blimit
  37.  
  38. - IMPLEMENT:    netrom blimit
  39.  
  40. - ping (record route) does not work
  41.  
  42. - brauchen die Broadcast Addressen noch das E-Bit?
  43.  
  44. ===============================================================================
  45.  
  46.     &TCB Rcv-Q Snd-Q  Local socket           Remote socket          State
  47.    62880     0  1017  dk5sg:ftp-data         dc3sn:1008             Closed
  48.  
  49. Local: dk5sg:ftp-data Remote: dc3sn:1008 State: Closed
  50.       Init seq    Unack     Next Resent CWind Thrsh  Wind  MSS Queue      Total
  51. Send: 3c580000 3c58e809 3c58e9ba  11233   432   216  1080  216  1017      59401
  52. Recv: 7538eff0          7538eff1      0              1080          0          1
  53. Backoff 11 Retrying Timer stopped SRTT 12130 ms Mean dev 7213 ms
  54.  
  55. ===============================================================================
  56.  
  57. - richtige Verwendung von Mycall pruefen
  58.  
  59. - "will echo" implementieren und testen (all telnet options)
  60.  
  61. - ax25 rtt cache?
  62.  
  63. - netrom rtt cache?
  64.  
  65. - rip request testen
  66.  
  67. - remote_kbd: stop tracing to stdout
  68.  
  69. - tty.h; ttydriv an session koppeln (Schwierigkeit: keine CmdSession)
  70.  
  71. - ttylink?
  72.  
  73. - trace for netrom selfconnects
  74.  
  75. - don't switch STREAM -> DGRAM after connection
  76.  
  77. - wo soll retry = 0 gesetzt werden ?
  78.  
  79. - AX.25:  VC Mode fuer IP einbauen
  80.  
  81. - AX.25:  axserver auch in die Liste haengen?
  82.  
  83. - AX.25:  gibt es mehrere strtopath ?
  84.  
  85. - Netrom:  Knoten sollen durch Ident ansprechbar sein
  86.  
  87. - Netrom:  print_destname ueberall verwenden
  88.  
  89. - Netrom:  den Ident wie eine AX25 Adresse behandeln
  90.  
  91. - Netrom:  struct circuit doppelt verpointern
  92.  
  93. - Netrom:  TTL default auf 25 erhoehen ?
  94.  
  95. - Mailer:  Alle Message Delimiter entfernen
  96.  
  97. - Mailer:  Use hierarchical addressing
  98.  
  99. - Mailer:  Use 'host-mode'
  100.  
  101. ===============================================================================
  102.  
  103. From dl5ue Wed Mar 22 14:44 MEZ 1989
  104. Received: by db0sao; Wed, 22 Mar 89 14:44:33 mez
  105. Date: Wed, 22 Mar 89 14:44:33 mez
  106. From: Jan Schiefer <dl5ue>
  107. Return-Path: <dl5ue>
  108. To: dk5sg
  109. Subject: netrom.c
  110. Status: R
  111.  
  112. Hallo Dieter,
  113.  
  114. leider bin ich erst heute dazu gekommen, mir netrom.c in Ruhe anzusehen. Am
  115. Montag war mir aufgefallen, dass von den WAMPI sehr haeufig gebroadcastet
  116. wurde. Heute trat das Problem scheinbar nicht auf, hast Du was geaendert?
  117.  
  118. Beim Lesen Deines Codes sind mir einige Dinge aufgefallen: In calculate_
  119. routes ziehst Du den Broacast-Timer auf 10s auf. Ich finde, man sollte da
  120. unbedingt eine Zufallszahl in der Groessenordnung 0...60s dazuaddieren, da
  121. sonst folgendes passieren koennte:
  122. A broadcastet Aenderungen, B und C hoeren dies, bei beiden ergeben sich
  123. auch Aenderungen. Sie starten ihre Broadcast-Timer und broadcasten zwar
  124. ohne Kollision, aber doch fast gleichzeitig. Da ist die Chance sehr gut,
  125. dass der Bs BC im TNC wartet, bis Cs BC vorbei ist. Anschliessend BCed B
  126. veraltete Routen, was wiederum A und C hoeren....usw.
  127.  
  128. Ausserdem fiel mir auf, dass auch bei einem BC 'ausser der Reihe' immer
  129. alle Routen gebroadcasted werden. Was haeltst Du davon, bei solchen BCs
  130. nur neighbor und quality derjenigen Destinations zu senden, bei  denen
  131. force_broadcast != 0 ist? Dadurch wuerde das Datenvolumen auf dem Kanal
  132. kleiner, ausserdem koennten mitlesende Spanner leichter beobachten, ob es
  133. Probleme bzw. Schwingungszustaende gibt. (Dann allerdings sollte man die
  134. normalen BCs grundsaetzlich immer machen, wenn der obsolesence_timer aus-
  135. laeuft, da sonst bei anderen Stationen der obs-counter u.U. veraltet, wenn
  136. laenger als 1/2 h kein vollstaendiger BC kommt).
  137.  
  138. Das was eigentlich das, was mir ins Auge stach. Ach ja, nochwas: So schwer
  139. ist das ja eigentlich gar nicht zu lesen + verstehen....
  140.  
  141. Gibt's was Neues von Deinem 70er Funk?
  142.  
  143. Bis bald,
  144. Jan
  145.  
  146. ===============================================================================
  147.  
  148. bbs mailer:
  149.  
  150. - wenn ich eine SID bekomme antworte ich mit meiner SID
  151.  
  152. - nach dem S Kommando wird auf OK/NO gewartet
  153.  
  154. - bei OK wird die Msg gesendet
  155.  
  156. - bei NO wird die Msg dem return_mailer uebergeben
  157.  
  158. - ich sende wenn moeglich hierachical adresses
  159.  
  160. ===============================================================================
  161.  
  162. HP:
  163. ---
  164.  
  165. ftp> put /hp-ux /tmp/x
  166. 200 PORT command okay.
  167. 150 Opening data connection for /tmp/x (127.0.0.1,1103).
  168. 226 Transfer complete.
  169. 802432 bytes sent in 6.72 seconds (116.58 Kbytes/sec)
  170.  
  171. ftp>
  172.  
  173. WAMPES:
  174. -------
  175.  
  176. put /users/funk/dk5sg/p.Z
  177. 200 Port command okay
  178. 150 Opening data connection for STOR /users/funk/dk5sg/p.Z
  179. Put complete, 3638 bytes sent
  180. 226 File received OK
  181.  
  182. ===============================================================================
  183.  
  184. S DC3SN    < DK7WJ
  185. OK, go ahead
  186. SEARCH U. WAMPES
  187. R:160289/1113  @DB0GV  [RMPRG Maintal-Frankfurt JO40KD OP: DF5FF (438.025 MHz)]
  188. de DK7WJ @ DB0GV
  189.  
  190. hallo Thomas, du hast den Finger auf der Wunde hi
  191. Ich hab die Sache bereits mit DB0IE ausprobiert, wo Wampes ja seit einiger
  192. Zeit auch laeuft. Der Suchframe (UI mit Poll) wird von Wampes normal
  193. digipeated, dummerweise aber nicht der Antwort-DM. Der wird von Wampes
  194. verschluckt, weil es vermutlich alle Frames ausser UI nur in dem High-
  195. Level-Pseudodigi (schoenes Wort) verarbeitet und dort feststellt, dass
  196. der DM zu keinem laufenden QSO gehoert. Also wird er verworfen.
  197. Bei Flexnet ist das so gemacht, dass alle Frames, die nicht zu einem QSO
  198. gehoeren, normal digipeated werden, was auch den Vorteil hat, dass bei
  199. vollen QSO-Tabellen oder nach einem Restart des Knotens die QSOs per
  200. L2-Digipeating weiterlaufen. Dadurch kommen auch die DMs durch. Diese
  201. Loesung bringt natuerlich auch noch weitere Schwierigkeiten, so muessen
  202. z.B. alle QSOs nach dem Disc noch ein paar Minuten weiter gefuehrt werden,
  203. damit die Trennung auch bei DISC-Retries noch funktioniert. Dies ist auch
  204. so gemacht, sie tauchen nur nicht mehr in der Userliste auf. Weiterer Vorteil:
  205. Noch vorhandene I-Frames bleiben fuer einen eventuellen Reconnect noch ne
  206. Weile gespeichert, leider fuehrt das manchmal zu doppelten Ctexten, aber das
  207. ist m.E. das kleinere Uebel.
  208. Der Suchframe ist ueberigens so aufgebaut, dass er garnicht zu einem laufenden
  209. QSO passen kann, der absendende Digi guckt naemlich erst in seiner QSO-Liste
  210. nach, ob der Gesuchte schon mit ihm connected ist. Wenn ja, wird sofort die
  211. "gefunden"-Msg gesendet.
  212. Waere fein, wenn Dieter die Sache bei Wampes umbauen koennte, ev. gleich
  213. mit Integration des Suchframes. Dieser sieht uebrigens wie folgt aus:
  214. <Absenderdigi> -> <Gesuchter> via <Suchender> <Absenderdigi>* [Digis] UI cp
  215. Leider ist im Moment der Link DA<->ID sehr schlecht, weshalb solche Frames
  216. leider oft verlorengehen... Wenn diese Msg nicht ausreicht, kann ich aber
  217. trotzdem gerne mal nen Suchpfad bei ODW einbauen, pse kurze msg!
  218. 73 Gunter   DK7WJ @ DB0GV
  219.  
  220. ===============================================================================
  221.  
  222. Hallo Jan, ich denk mir eben dass ich euch die Konzeptbaustelle schon mal
  223. zuschicke, dann koennt ihr parallel daran arbeiten und Fehler suchen helfen.
  224. Zum Codieren komm ich eh erst in 2-3 Wochen, vorher gibts fuer den RMNC noch
  225. nen Update mit einigen Features mehr und einigen Bugs weniger, die Version
  226. mit Router will ich so ca. zur Ham Radio fertig haben... kann sein dass in
  227. dem folgenden Papier noch Fehler drinstecken, ist wie gesagt nur der Entwurf
  228. fuer das Skript, also pse Nachsicht... so los gehts:
  229.  
  230.                     Features FlexNet Sink-Tree-Router      Stand: 20.04.89
  231.                     =================================
  232.  
  233. -   Netzknoten unterhalten untereinander staendig eine L2-Verbindung fuer
  234.     Routing Updates und zur Kontrolle des Links
  235. -   Nach (Wieder-)anlauf eines Knotens hat dieser keinerlei Informationen ueber
  236.     die Netztopografie, die Kenntnis seiner Nachbarn ausgenommen. Also meldet
  237.     der Knotes diese Tatsache seinen Nachbarn, worauf diese ihm sofort alle
  238.     ihnen bekannten Nodes zuspielen, diese Info enthaelt einen Parameter fuer
  239.     die Route-Qualitaet, die analog zur Netrom-Loesung ermittelt wird.
  240. -   Unser Knoten hat nach dieser ersten Lernphase eventuell mehrere Routes zu
  241.     einem Ziel erhalten, er speichert die 3 besten und benutzt hinfort den
  242.     besten.
  243. -   Diese Liste wird nun durchgesehen, unser neunmalkluger Knoten hat nun
  244.     sicherlich fuer manche Ziele viel bessere Pfade gelernt, als er sie von
  245.     einem seiner Nachbarn gemeldet bekam. Sicher gilt das z.B. fuer die jeweils
  246.     anderen Nachbarn, zu denen er ja bereits eine Verbindung unterhaelt.
  247.     Jetzt wird es aber kritisch: Meldet er diese besseren Pfade einfach weiter,
  248.     kann es passieren, dass nach einem Ausfall dieser momentan noch besseren
  249.     Strecken eine Loop entsteht, denn er wuerde ja dann sofort den zweitbesten
  250.     Weg waehlen, der dann aber leider genau der Rueckweg ist. Um dieses Problem
  251.     zu loesen, greifen wir zu einem Algorithmus, der in der Literatur als "Sink
  252.     Tree" bekannt ist.
  253.  
  254.     Bezogen auf ein bestimmtes Ziel steht jeder Knoten an einer Gabelung eines
  255.     Baumes. Er muss stets informiert sein, wo in diesem Baum die Nachbarn
  256.     angeordnet sind, d.h. ob sie auf dem Weg zum Ziel liegen oder ob umgekehrt
  257.     diese ihre Packets fuer den Zielknoten ueber uns routen. Er darf NIEMALS
  258.     Packets in der Gegenrichtung routen, also zu einem Knoten, der von ihm aus
  259.     weiter hinten liegt. Wenn wir nun den Ausfall unserer Strecke bemerken und
  260.     auch keine Alternative im obigen Sinne finden, senden wir einen Hilferuf an
  261.     die Knoten unter uns: "Ich kann Knoten x nicht mehr erreichen!" Wenn der
  262.     Knoten darunter eine Alternative hat, sendet er diese Information zurueck,
  263.     der Fall ist erledigt, fuer dieses Ziel haben die beiden Knoten ihre
  264.     Position auf dem Baum getauscht. Wenn unser Nachbar auch keine Alternative
  265.     kennt, sendet er diesen Hilferuf ueber alle Links weiter. Dies setzt sich
  266.     fort, bis irgendwo im Netz ein Knoten einen alternativen Weg kennt. Diese
  267.     wird dann normal bekanngemacht, wobei die Knoten ihren neuen Platz auf dem
  268.     Baum einnehmen. Die Hilferufe fuehren natuerlich bei jedem Knoten dazu, dass
  269.     die entsprechende Routinginformation geloescht wird. Wohlgemerkt: Dieser
  270.     Baum existiert fuer jedes im Netz bekannte Ziel, Die Implementierung der
  271.     Nodestabelle ist recht einfach: Fuer jeden Nachbarn wird eine Spalte
  272.     eingerichtet, in der die Streckenqualitaeten zum jeweiligen Zielknoten
  273.     stehen. Ein Nachbar, der ueber uns routet, wird mit der Qualitaet 0
  274.     versehen. Wenn wir einem Nachbarn eine Linkinfo senden, gehen wir immer erst
  275.     davon aus, dass dieser den Weg ueber uns auch benutzen darf. Sofern er uns
  276.     eine Strecke meldet, wird er niemals ueber uns routen, und wir koennen
  277.     diesen Weg verwenden.
  278.  
  279.     Wenn wir keinen verwertbaren Weg zu einem Ziel mehr haben, senden wir auf
  280.     allen Links einen Hilferuf aus, der besagt, dass wir keinen Weg zum
  281.     Zielknoten mehr kennen. Die Nachbarn loeschen draufhin den Weg ueber uns und
  282.     schauen dann nach, ob sie eine Alternative haben: Wenn ja, teilen sie sie
  283.     uns mit, wenn nein, senden sie den Hilferuf weiter. Dies setzt sich fort,
  284.     biss alle Knoten den Ruf erhalten haben und keiner einen Pfad zum Ziel
  285.     kennt. Gibt es jedoch einen solchen, dann wird diese Information wie beim
  286.     Kaltstart verbreitet. Die Routinginformationen fuer diesen Zielknoten bauen
  287.     sich dann neu auf, sobald irgendwo ein Weg bekannt ist. Wenn ein Knoten
  288.     nicht mehr erreichbar ist, wird er auf diesem Wege aus allen Knoten
  289.     ausgetragen.
  290.  
  291. --------------
  292.                     Datenstruktur Routing Table
  293.                     ===========================
  294.  
  295. Fuer jede gemeldete Node ein Eintrag, ausser fuer die Nachbarn, diese
  296. stehen samt Kanalnummer in einer eigenen Liste (Nachbarliste)
  297.  
  298. <CALL(7)> <3*[<Nachbar-Nummer>,<Qualitaet>]> <Upstr Flags> <Updt Flags>
  299.  
  300. Nachbar-Nummer: Index in Nachbarliste
  301. Qualitaet: Link-Qualitaet, Berechnung wie NET/ROM
  302. Upstr-Bitflags: Fuer jeden Nachbarn ein Bit als Kennung: Nachbar ist Upstream
  303. Updt-Bitflags: Fuer jeden Nachbarn ein Bit als Kennung: Update Info senden
  304.  
  305. Summe: 21 Bytes/Node bei max. 32 Nachbarn
  306.  
  307.            Verwaltung der Routing Table (Pseudocode)
  308.            =========================================
  309.  
  310. Kaltstart:
  311.     {
  312.     Routing Table loeschen
  313.     Hauptschleife:
  314.         {
  315.         Alle ca. 5 Minuten:
  316.             {
  317.             L2-QSO zu L3-Nachbarn initiieren, falls nicht connected
  318.             ((( Nachbarn identifizieren, Versionen abgleichen )))
  319.             }
  320.  
  321.         Neues L2-QSO mit bekanntem Nachbar:
  322.             {
  323.             In allen Routes Update-Flags fuer diesen Nachbarn setzen
  324.                 und Upstream-Flags loeschen
  325.             }
  326.  
  327.         L2-QSO zu Nachbar zusammengebrochen:
  328.             {
  329.             Alle Flags (Update und Upstream) fuer diesen Nachbarn loeschen
  330.             Route-Qualitaeten via diesem Nachbarn loeschen, wenn dadurch
  331.                 zu Zielen der beste Weg verlorengeht, Update-Flags fuer alle
  332.                 Upstream-Nachbarn fuer dieses Ziel setzen, d.h. Update-Bits
  333.                 von Upstream kopieren
  334.             }
  335.  
  336.         periodisch (z.B. alle 100ms eine Route oder alle 10s alles)
  337.             {
  338.             Plaetze ohne verwendbaren Weg loschen, falls kein Update-
  339.             Flags gesetzt
  340.  
  341.             Eine Route auf gesetzte Update-Flaggen testen:
  342.                 {
  343.                 Routing Info senden, wenn gelungen, Update loschen und
  344.                     Upstream setzen, sofern gemeldete Qualitaet > 0
  345.                 Eventuelle Route-Qualitaet via diesem Nachbarn auf 0 setzen!!
  346.                 }
  347.             }
  348.  
  349.         Route-Info erhalten?
  350.             {
  351.             Neue Node && Qualitaet > 0 (kein Hilferuf)?
  352.                 {
  353.                 Tabellenplatz fuer Node einrichten, alles auf 0 setzen
  354.                 }
  355.  
  356.             Qualitaet > 0?
  357.                 {
  358.                 Upstream-Flag f. Nachbar loeschen
  359.                 }
  360.  
  361.             Gemeldete Qualitaet <= den bekannten?
  362.                 {
  363.                 Wenn dieser Nachbar besser ueber uns ginge, da sich fuer ihn
  364.                 ein besserer Weg ergibt als gemeldet, Update Flag setzen!
  365.                 }
  366.  
  367.             Bereits 3 Routes gespeichert?
  368.                 {
  369.                 Schlechteste Route loeschen und neue Route eintragen, falls
  370.                 nicht die schlechteste
  371.                 }
  372.  
  373.             Beste Qualitaet besser geworden (auch wenn neue Node!)
  374.                 {
  375.                 Fuer alle Nachbarn mit eingetragenen Qualitaeten berechnen,
  376.                 ob sie ueber uns besseren Weg haetten, wenn ja->Update-Flag
  377.                 }
  378.  
  379.             Durch Meldung beste Qualitaet schlechter geworden?
  380.                 {
  381.                 Fuer alle Nachbarn OHNE eingetragene Qualitaet Update-Flag
  382.                 ausser fuer den meldenden Nachbarn
  383.                 }
  384.             }
  385.  
  386.                     Syntax Routing Updates
  387.                     ======================
  388.  
  389.     --- noch zu definieren (moeglichst eigene PID)
  390.  
  391.                     Link-Qualitaeten
  392.                     ================
  393.  
  394. Aufgrund dews Sink-Tree-Algorithmus ist es unabdingbar, dass eine Strecke
  395. auf beiden Seiten die gleiche Qualitaet besitzt. Alternativ koennte man
  396. in der Setup-Phase eines QSOs zwischen Nachbarn die eigene Qualitaet
  397. uebertragen. Ein automatisches Update der Qualitaet in Abhaenigkeit der
  398. Belegung erscheint nicht sinnvoll, da dies zu zuvielen Updates im Netz
  399. fuehren kann. Folgende Qualitaeten werden beim RMNC voreingestellt
  400. (Aenderung durch Sysops nicht vorgesehen):
  401.  
  402.           Baudrate   Vollduplex  Halbduplex
  403.  
  404.             9600        252         249
  405.             4800        249         243
  406.             2400        243         232
  407.             1200        232         211
  408.              600        211         175
  409.              300        175         120
  410.  
  411. Die Berechnung einer Route-Qualitaet geschieht wie bei NET/ROM:
  412.                 Rc' = (Cc * Rc + 128)/256
  413.  
  414. Rc': Neue Routequalitaet; Rc: Alte Routequalitaet; Cc: Kanalqualitaet
  415.  
  416.                     Routing-Algorithmus
  417.                     ===================
  418.  
  419. Konzept:
  420.    Virtual Circuit Router unter Verwendung des AX25-Adressfeldes
  421.  
  422. Wird bei FlexNet-QSOs nur bei SABM und UI durchlaufen, ausserdem bei
  423. Frames, die nicht zu einem laufenden QSO passen.
  424. Routing uebertragbar auf Digis ohne Hop-to-Hop-Ack
  425.  
  426. Wir sind nicht naechster Digi?
  427.     {
  428.     verwerfen!
  429.     }
  430.  
  431. Wenn auf exclusivem Linkkanal empfangen: Letztes Call als Nachbar
  432.   bekannt?
  433.     {
  434.     verwerfen!
  435.     }
  436.  
  437. Letztes Call als Nachbar bekannt && nicht 1. Digi && vorletztes Call als
  438.   Node bekannt?
  439.     {
  440.     Letztes Call aus Callfeld loeschen, folgende Calls aufruecken
  441.     }
  442.  
  443. Naechstes Call als Node bekannt && Route vorhanden?
  444.     {
  445.     Call des Nachbarn, ueber den gerouted wird, nach unserem einschieben
  446.     }
  447.  
  448. Jetzt routen nach V2-Methode, also entsprechend SSID oder Nachbarn
  449.  
  450. H-Bit und ev. SSID fuer unser Call setzen
  451.  
  452. Frame senden (Bei FlexNet-SABM QSO-Allokierung)
  453. }
  454.  
  455.                 Vorteile von FlexNet Virtual Circuit
  456.                 ====================================
  457.  
  458. - Keine Fragmentierung von langen I-Frames durch Network Header Overhead
  459. - Das vorhandene Digipeaterfeld im AX.25-Protokoll wird sinnvoll weiter-
  460.   verwendet
  461. - Jede monitorende Station sieht sofort, wer mit wem ueber welche Strecke
  462.   arbeitet, Up- und Downlink sind symmetrisch, d.h. man kann die anrufende
  463.   Station ueber den gemeldeten Pfad zurueckconnecten
  464. - Deutlich groesserer Durchsatz durch:
  465.     a) Entfall des Rechenaufwandes durch Routing jedes einzelnen I-Frames
  466.     b) Kein festes End-to-End-Window, das Window ergibt sich durch die
  467.        Summe der eingestellten MAXFRAMES der auf der Strecke liegenden
  468.        Knoten
  469.     c) Fuer jedes QSO individuelles Flow-Control moeglich, dadurch optimale
  470.        Auslastung von schnellen Teilstrecken; ueberlastete, weil z.B. lang-
  471.        same Teilstrecken bremsen nur noch die QSOs, die ueber diese Strecken
  472.        laufen muessen
  473.  
  474. - Durch die Transparenz Unprotos und andere Protokollvarianten moeglich, z.B.
  475.   Netrom-Vekehr ueber FlexNet-Teilnetze mit 2 anzugebenden Digis
  476. - Keinerlei Einschraenkungen bezueglich PIDs
  477. - Einstufiger Verbindungsaufbau mittels Angabe von Einstiegs- und Ausstiegs-
  478.   knoten
  479. - Endstellen, die als Nachbarn definiert sind (z.B. Mailboxen), koennen
  480.   von entfernten Knoten ohne Angabe des letzten Digis connected werden,
  481.   z.B. "C DB0CZ via DB0ODW"
  482. - Wenn beim Verbindungsaufbau bei einem Knoten auf der Strecke kein RAM frei
  483.   ist, wird QSO nach gleichem Routingverfahren auf dieser Teilstrecke per
  484.   L2-Digipeating ausgefuehrt, dadurch kein hartes Limit der QSO-Anzahl
  485. - Sehr einfache Implementierung, zumindest bei FlexNet und, wenn ohne Hop-
  486.   to-Hop-Acknowledge realisiert, auch bei anderen Knotenrechnerkonzepten
  487. - Durch Entfall des speziellen L4 kuerzerer Code
  488.  
  489.             Nachteile gegenueber Datagram-Routing (z.B. NET/ROM)
  490.             ====================================================
  491.  
  492. - Jedes QSO, das ueber einen Netzknoten abgewickelt wird, belegt Speicher-
  493.   platz, sofern es per Hop-to-Hop-Ack abgewickelt wird (bei FlexNet ca.
  494.   200 Bytes + zwischengespeicherte Frames)
  495. - Dynamisches Umrouten bei WAEHREND eines QSOs ausgefallenen Knoten und
  496.   Strecken nicht moeglich, Verbindung muss neu aufgebaut werden
  497.    (Riesennachteil!! Relativiert durch durchschnittliche QSO-Dauer, zuver-
  498.     laessiges Netz, Zusammenbruch ergibt aussagekraeftige Fehlermeldung des
  499.     Knotens, der die Verbindung nicht weiterfuehren konnte)
  500. - Es koennen mehr als 8 Digis im Rufzeichenfeld entstehen, dieser Fall muss
  501.   entsprechend behandelt werden, entweder zurch Zulassen von 10 Digis oder
  502.   durch Verwerfen dieser Frames
  503.  
  504.                        Auswirkungen fuer User
  505.                        ======================
  506.  
  507. - User brauchen sich nicht umzustellen, es kann nach wie vor der komplette
  508.   Pfad angegeben werden
  509. - User kann am Einstiegsdigi die Nodesliste abrufen, wenn sein Ausstiegsdigi
  510.   in der Liste steht, kann er die dazwischenliegenden Digis weglassen
  511. - Nach wie vor einstufiger Verbindungsaufbau ueber das bekannte Netzwerk
  512. - Uebergang erfolgt gleitend, Vorteile entstehen sobald min. 3 Digis in
  513.   Reihe dieses Verfahren beherrschen (mittlerer Digi kann weggelassen werden)
  514.  
  515.                   Allgemeine Argumente gegen NET/ROM
  516.                   ==================================
  517.  
  518. 1. Router (L3)
  519.   - Ein Netzknoten besteht in Wirklichkeit aus mehreren "Nodes", die man
  520.     zwar verstecken kann, aber sie existieren und belasten die Routing-
  521.     tabellen
  522.   - NET/ROM hat Schwierigkeiten mit Loops, die beim Ausfall von Linkstrecken
  523.     oder Netzknoten entstehen koennen
  524.   - Ausgefallene Nodes werden zu langsam bekanntgemacht, Erhoehen der Update-
  525.     rate belastet Netz zu stark, zumindest bei 1200 Baud-Links
  526.   - Durch Sendung der Routinginfo als Broadcast geringe Uebertragungssicher-
  527.     heit, u.a. deshalb periodische Wiederholung noetig
  528.   - Konzipiert fuer ein sehr dynamisches Netz mit vielen Linkpartnern auf
  529.     einer Frequenz, daraus resultieren z.T. obige Maengel.
  530.   - Prinzipbedingt (Datagram Routing) Probleme mit Flow Control, dadurch
  531.     u.U. schlechte Frequenzauslastung
  532.  
  533. 2. Transport (L4)
  534.   - Trennen der Verbindung nach ~10 Minuten ohne Aktivitaet, waere behebbar
  535.     durch "L4V2" mit Command/Poll
  536.  
  537. 3. Up-Downlink
  538.   - Beim Monitoren ist der Pfad nicht ersichtlich
  539.   - Zwecks Rueckruf muss der Einstiegsdigi des Partners bekannt sein
  540.   - SSID-Drehung, dadurch eingeschraenkte Verwendbarkeit von SSIDs und
  541.     moegliche Irrtuemer beim Zurueckconnecten
  542.   - Verbindungsaufbau uebers Netzwerk generell dreistufig, dadurch kein
  543.     automatischer Verbindungsaufbau mit normalen Terminalprogrammen durch
  544.     Funktionstastenbelegung moeglich
  545.   - "Weiterconnecten" fuehr bei vielen QSOs zu Zickzackroutes mit unnoetiger
  546.     Netzbelastung
  547.   - Digi sendet nicht unter seinem Rufzeichen, dadurch z.B. Irrtuemer bei
  548.     Feldstaerkeermittlung
  549.  
  550. Sodele, oje, ist doch schon etwas laenglich fuer diese Betriebsart hi
  551. also, bei Bedarf werd ich die Updates auch wieder rueberspielen, hab aber
  552. wie gesagt in den naechsten Tagen sehr wenig Zeit fuer den Kram
  553. 73 Gunter
  554.  
  555. ===============================================================================
  556.